1. Field of the Invention
The present invention relates to a system, method, and computer program product for providing improved performance for queries on local partitioned indexes of spatial data using the root minimum bounding rectangles of the partitions of the indexes.
2. Description of the Related Art
In a relational database, data is stored in two-dimensional tables that are composed of rows and columns. The database management system manages the data in the database and enables a user to store data, update it, and retrieve it.
The database management system is software that provides the capability to create and manage the database. A typical database consists of physical and logical structures in which system, user, and control information is stored. Because the physical and logical structures are separate, the physical storage of data can be managed without affecting the access to logical storage structures.
One type of data that may be stored in a database is spatial data. A common example of spatial data can be seen in a road map. A road map is a two-dimensional object that contains points, lines, and polygons that can represent cities, roads, and political boundaries such as states or provinces. A road map is a visualization of geographic information. The location of cities, roads, and political boundaries that exist on the surface of the Earth are projected onto a two-dimensional display or piece of paper, preserving the relative positions and relative distances of the rendered objects.
The data that indicates the Earth location (latitude and longitude, or height and depth) of these rendered objects is the spatial data. When the map is rendered, this spatial data is used to project the locations of the objects on a two-dimensional piece of paper. A GIS is often used to store, retrieve, and render this Earth-relative spatial data.
Types of spatial data that can be stored using Spatial other than GIS data include data from computer-aided design (CAD) and computer-aided manufacturing (CAM) systems. Instead of operating on objects on a geographic scale, CAD/CAM systems work on a smaller scale, such as for an automobile engine or printed circuit boards.
A DBMS that handles spatial data includes spatial features that let a user store, index, and manage location content (assets, buildings, roads, land parcels, sales regions, and so on.) and query location relationships using the power of the database. The DBMS may also support advanced spatial features such as linear reference support and coordinate systems.
In a typical DBMS, after spatial data has been loaded into the database, a spatial index is created on the data to enable efficient query performance using the data. Once data has been loaded into the spatial tables through either bulk or transactional loading, a spatial index must be created on the tables for efficient access to the data. In many DBMSs, it is possible to create partitioned spatial indexes.
Modern enterprises frequently run mission-critical databases containing upwards of several hundred gigabytes and, in many cases, several terabytes of data. These enterprises are challenged by the support and maintenance requirements of very large databases (VLDB), and must devise methods to meet those challenges. One way to meet VLDB demands is to create and use partitioned tables and indexes. Partitioned tables allow your data to be broken down into smaller, more manageable pieces called partitions, or even subpartitions. Indexes can be partitioned in similar fashion. Each partition is stored in its own segment and can be managed individually. It can function independently of the other partitions, thus providing a structure that can be better tuned for availability and performance.
Partitions and subpartitions of a table or index all share the same logical attributes. For example, all partitions (or subpartitions) in a table share the same column and constraint definitions, and all partitions (or subpartitions) of an index share the same index options. They can, however, have different physical attributes.
Queries on a “local partitioned index” (i.e., a table that has local indexes one per partition) are answered by posing the query on each partition (identified by the database engine using the non-spatial part of the query predicate). This is terribly slow, as the query is processed afresh for each partition, the metadata is read for each partition and so on. A need arises for a technique that provides improved performance for queries on local partitioned indexes.